23章 デバッグ
23.2.2 までakht.icon
23.2.3 からtommy.icon
デバッグ = エラーの原因をつきとめ、それを修正するプロセス
※テスト = エラーの検出
プロジェクトによってはデバッグが開発全体の50%をしめるらしい
23.1 デバッグの概要
ソフトウェアのバグはプログラマがミスを犯したことを意味する
デバッグの役割
ソフトウェア自体の品質が改善されるとは限らない
そもそも品質は最初から作り込んでおかないといけない
デバッグのパフォーマンス
デバッグの方法は誰でも知ってるとは限らないし、スピードにも個人差がある
最も遅いグループがプログラムを完全にデバッグするには、最も速いグループの約13倍もの時間がかかる計算になる。
最も速いプログラマは最も多くの欠陥を検出し、最も速く欠陥を検出し、最も多くの欠陥を正確に修正した。
品質、コスト、時間を秤にかける必要はない。それらは同時に達成できる。
23.1.3 機会としての欠陥
プログラムに欠陥があってほしくないという願望 = プログラムが何をするのか完全に理解していない
= 試行錯誤のプログラミング = 欠陥が紛れ込むのが保証されてるようなもの
エラーからは多くのことが学べる
作業してるプログラムはどんなものか
エラーの種類はどのようなものか
エラーがあった日はチャンス = 他の箇所を調べるいいきっかけになる
読み手の立場に立ってコードの品質を調べる
エラーがあったらコードを読むことになる = 品質を評価するチャンス（改善に繋げられる）
問題をどのように解決しているか調べる
欠陥をどのように修正しているか調べる
23.1.4 効率の低いアプローチ
憶測で探す
そこら中にprint文を書く、うまくいくまでコードを変更する
問題を理解しようとしない
真っ先に思いついた（場当たり的な）方法で問題を修正する
迷信に基づくデバッグ
23.2 欠陥の検出
欠陥を検出して、それを理解することがデバッグ作業の9割
殺人事件の解決方法
全国民のアリバイを調べるのか
犯人を特定するような手がかりを探すのか
科学的な方法、発見と立証
科学的なデバッグ
科学的な手法
1. 再現性のある実験でデータを収集
2. データから仮説を立てる
3. 仮説を立証または反証する実験を準備
4. 仮説を立証または反証する
5. 繰り返す
科学的な手法をデバッグに応用する
1. エラーを再現させる
2. エラーの原因を特定する
1. 再現するデータを集める
2. 仮説を立てる
3. 立証または反証する方法として、テストとコードのどちらを調べるか判断
4. 判断した手順によって仮説を立証または反証する
3. 欠陥を修正する
4. テストする
5. 同様のエラーを探す
エラーを安定させる = 再現させる
再現性のないエラーを診断することはほぼ不可能
初期化エラー、タイミングの問題、ポインタの問題
再現ケースは出来るだけ絞り込んだ単純なものにする
エラーの原因を特定する
同じように科学的な方法をとる
仮説 -> 検証
23.2.2 欠陥を検出するためのヒント
エラーを簡単に特定できるかどうかはコードがどれだけうまく書かれているかによって決まる
エラーがなかなか見つからない場合
手に入る全てのデータを使って仮説を立てる
エラーを再現させるテストケースを改良する
複数の単体テストでコードをテストする
ツールを使う
分析的に診断するのが難しい問題でもツールを使えば単純な問題になることもある
何種類かの方法でエラーを再現する
データをさらに収集して仮説を増やす
仮説が反証された事実も利用する
範囲が絞り込まれる
新しい仮説をひねり出す
一つの仮説にしがみつかず、思いつく限りの仮説をガーッと立てて、それぞれ検討する
メモる
疑わしいコードの範囲を絞り込む
コードを消してみる
この時、でたらめに消さず二分探索的にやる
以前に欠陥があったクラスやルーチンを疑う
最近変更されたコードをチェックする
調査範囲を広げる
統合はインクリメンタルに行う
まっさらな状態からコードを足していき、どこでエラーが発生するかみる
一般的なエラーをチェックする
誰かと問題について話す
告白デバッグ
他人にエラーを説明していると自分のミスに気づくことがある
問題から離れてみる
ブルートフォースデバッグ
間に合わせのデバッグには制限時間を設ける
最初からブルートフォースやっとけばよかった...とならないように
ブルートフォース手法をリストアップする
面倒だけど問題を修正できることが保証される方法があるか、あらかじめ用意できているといい
hr.icon
23.2.3 構文エラー
tommy.icon コンパイラをあてにしないってのは最近のRustみたいな言語だと言えないよなぁと思った 23.3 欠陥の修正
tommy.icon 修正による更なる不具合が怖くて慎重になるけど自信を持って修正できる取り組みをしていきたい
リラックスする
tommy.icon バスケットボールのやついい話
症状ではなく問題を修正する
tommy.icon 例ほど極端ではないもののアドホックな修正やりがちなので気をつけたい
23.4 デバッグの心理学的考察
tommy.icon 特に引っかからなかった
23.5 デバッグツール
23.5.2 コンパイラの警告メッセージ
tommy.icon この辺はJetBrains製IDEだと警告のレベルを調整できたりする 23.5.4 実行プロファイラ
tommy.icon この辺は新人氏がうまく使ってたなぁ
23.5.6 デバッガ
tommy.icon この辺、環境が整ってないので整えられるといいっすなぁ